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Field of the Invention 

The invention relates to a system for generating and 
transmitting message playlists to remotely located optical 
disc players for playing selected messages via a music on- 
5 hold- compatible telephone system or public address system. 
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Many businesses use music on-hold-compatible (MOH) 
telephone systems to provide a customer with music or 
audio promotions of products or services while the 
customer is placed on-hold and waiting for assistance. A 
number of existing MOH telephone systems use tape players 
as the audio source. The promotional messages are 

recorded on endless loop cassette tapes. These systems are 
disadvantageous because the tapes are subject to wear, and 
the tape players are prone to mechanical malfunctioning. 
Messages are not modified (i.e., adding or deleting 
individual messages from a message playlist or modifying 
the sequence for playing messages on the playlist) because 
an individual message track cannot be accessed without 
first winding the tape forward or backward, respectively, 
past the succeeding or preceding message tracks. Thus, 
tapes requiring modification are usually discarded, and a 
new tape is purchased and recorded with messages in 
accordance with a new message playlist. 

Another type of existing MOH telephone system 
eliminates the use of a tape player by downloading 
digitized audio messages onto an integrated circuit (IC) 
chip. The stored messages are played in a particular 
sequence that is repeated. While the number of moving 
parts that are subject to mechanical failure is reduced, 
the system is nonetheless disadvantageous because it is 
does not allow a user to program when an individual 
message is to be played or to add or delete a message from 



- 3 - 



a playlist or modify the sequence with which the stored 
messages are played. 

An improved MOH telephone messaging system is 
disclosed in U.S. patent application Serial No. 
5 07/999,592, filed December 31, 1992, for ON-HOLD MESSAGING 
SYSTEM AND METHOD, the entire subject matter of which is 
hereby incorporated herein by reference for all purposes. 
The improved MOH telephone messaging system uses at least 
one optical disc player, such as a compact disc player 

10 (CDP) , as the audio source. A CDP delivers improved sound 
quality and offers the ability to add or delete individual 
messages from a playlist and to change the play sequence 
of messages stored on an optical disc. For example, the 
CDP can be programmed to not play one or more of the 

15 stored messages at all. Thus, a message playlist can be 
altered without purchasing and recording a new message 
storage medium, unlike audio sources which use a cassette 
tape or an IC. The disclosed CDP-based telephone 

messaging system, however, is not remotely programmable. 

20 

Summary of the Invention 

In accordance with an aspect of the present 
invention, a remotely programmable message delivery system 
is provided which allows users to specify message 
2 5 sequences that are to be played at one or more remote 
sites via an MOH telephone system or other advertising 
device such as a public address system. The message 
delivery system comprises a communication link and a 
plurality of message playback devices, each of the message 
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playback devices comprising a storage device for storing a 
plurality of audio messages . A computer remotely located 
from the plurality of message playback devices transmits 
control signals via the communication link for controlling 
5 at least one of the plurality of message playback devices . 
Each of the plurality of message playback devices is 
adapted to receive the control signals via the 
communication link. The computer is programmable to 
generate screens for guiding an operator to make choices 

10 selected from the group consisting of: which of the audio 
messages is to be played, which of the plurality of 
message playback devices is to play the selected audio 
message (s), which of a number of subsets of the plurality 
of message playback devices is to play the selected audio 

15 message (s), and the order in which multiple selected audio 
messages are to be played, and to generate control signals 
to implement these choices . 

In accordance with another aspect of the present 
invention, the computer generates a screen displaying a 

20 location directory and a message directory. A user can 
select messages from the message directory for play at 
different remote sites selected from the location 
directory, as well as specify the sequence in which the 
selected messages are to be played at each selected remote 

25 site. 

In accordance with yet another aspect of the present 
invention, the computer generates a location directory 
comprising the names of regions and the names of remote 
sites located in each of the regions. The computer is 
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programmable to allow a user to add and delete remote site 
names in the location directory, as well as to create, 
modify and delete regions . The computer can generate a 
single command for a number of message playback devices 
5 located in the same region to play the same message 
playlist. 

In accordance with still another aspect of the 
present invention, the computer is programmable to 
generate a screen which allows a user to select a message 

10 from the message directory and to display a full text 
script of the message. 

In accordance with still another aspect of the 
present invention, the computer is programmable to 
generate control signals and provide them to a radiopaging 

15 company for transmission to the remote sites via 
radiopaging signals . 

In accordance with still another aspect of the 
present invention, the system comprises a plurality of 
computers configured as client computers, and a central 

2 0 computer with which all of the client computers 
communicate via a communication link. The central 

computer receives data from the client computers relating 
to user choices for message playlists at selected remote 
sites and transmits the data to the remote sites via the 

25 same or another communication link. The central computer 
can communicate with a radiopaging company to transmit the 
data via radiopaging signals . 

In accordance with still another aspect of the 
present invention, the message playback devices each 




- 6 - 



comprise a compact disc player and a receiver circuit for 
receiving radiopaging signals transmitted by via a 
radiopaging company. The receiver circuit recognizes 
radiopaging signals directed to it and commands the 
5 compact disc player to play the message tracks specified 
in the radiopaging signals at the time and in the sequence 
requested by the client computer from which the message 
playlist data for the radiopaging signals originated. 

10 Brief Description of the Drawings 

These and other features and advantages of the 
present invention will be more readily apprehended from 
the following detailed description when read in connection 
with the appended drawings, which form a part of this 
15 original disclosure, and wherein: 

Fig. l/ is a schematic block diagram of a remotely 
programmable messaging system constructed in accordance 
with an embodiment of the present invention; 

Fig. 2/ is a schematic block diagram of a message 
2 0 playback device constructed in accordance with an 
embodiment of the present invention and connected to a 
conventional MOH telephone system; 

Fig. 3 is a schematic block diagram of a client 
computer constructed in accordance with an embodiment of 
25 the present invention; 

Fig. 1 is a schematic block diagram of a server in a 
remotely programmable messaging system constructed in 
accordance with an embodiment of the present invention; 
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Fig. S y^^' 7 ' 8 ' 9# 10 ' 11 ' 12 ' 13 ' 14 ' 15 ' 16 ' 17 
and 18 are tables for storing data in a distributed 
database constructed in accordance with an embodiment of 
the present invention; 
5 Figs. 19/ 20, 21, 22, 23, 24, 25, 26, 27 and 28 are 

screens generated by a client computer for guiding a 
client to enter message playlist data in accordance with 
an embodiment of the present invention; 

Fig. 29 is a schematic block diagram illustrating 
10 software modules in a server constructed in accordance 

with an embodiment of the present invention; 

■/ 

Fig. 3 ; 0 depicts the format of a packet transmitted 

between a client computer and a server in accordance with 

an embodiment of the present invention ; 
15 Fig. 3l/ 32, 33, 34, 35, 36, 37, 38, 39 and 40 

illustrate fields in different packets transmitted between 

a server and a client computer in accordance with an 

embodiment of the present invention; 

Fig. 41 illustrates the format of a packet 
2 0 transmitted between a server and a message playback device 

in accordance with an embodiment of the present invention; 

Fig. 42 yds a diagram depicting an encoding process in 

accordance with an embodiment of the present invention; 

and J 
25 Figs. 43, 44, 45, 46, 47, 48, 49, 50, 51 and 52 

illustrate fields in packets transmitted between a server 

and a message playback device in accordance with an 

embodiment of the present invention. 
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Detailed Description of the Preferred Embodiments 

Fig. 1 depicts a message delivery system 10 for 
remotely controlling the playback of messages at a number 
of remote sites via message playback devices. The term 
5 "message" used herein refers to music, advertisements or 
other recorded audio signals which can be played for a 
person whose telephone call has been answered by a MOH 
telephone system. In addition, the system 10 can be 
configured to program remote, multimedia message playback 

10 devices, in which case a message can comprise video or 
other data, as well. The system 10 comprises at least one 
central administrative computer 12 hereinafter referred to 
as a server. The server 12 receives message playback 
data, including sequences of selected messages 

15 {hereinafter referred to as playlists) that originate from 
a number of client computers 14a and 14b, and uses the 
message playback data to command message playback devices 
24 at selected remote sites to play selected messages . 
Thus, message playback data can comprise identification of 

20 selected remote sites at which the messages are to be 
played, as well as other data such as effective dates for 
playlists (i.e., the dates on which the server 12 actually 
transmits the playlists to the message playback devices) . 
Two computers 14a and 14b are shown for illustrative 

25 purposes, although more client computers can be used in 
the system 10. The system 10 can comprise more than one 
server 12, for example, if the amount of data received 
from the computers 14 exceeds the processing capability of 
a single server 12 . The server 12 and the client computers 
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14 are preferably IBM-compatible personal computers (PCs) , 
although other platforms such as UNIX and Macintosh can be 
used. The computers 14 are adapted to communicate with 
the server 12 via a communication network 16 such as a 
5 public switched telephone network (PSTN) . The network can 
also be a private network with a private branch exchange 
(PBX) , a radiopaging network, an optical fiber network, a 
microwave network, a satellite network, and the like. 

The computers 14 are used by clients to enter 

10 information relating to the generation of messages at one 
or more remote sites. As shown in Fig. 1, three remote 
sites 18, 20 and 22 are each provided with one or more 
message playback devices 24a, 24b, 24c and 24d, 
respectively. For example, a first client can be a bank 

15 which uses the computer 14a to send message playlists and 
other information to bank branches located at sites 18 and 
20, respectively. A second client can be a product 
distributor which uses the computer 14b to send message 
playlists to a regional office at site 22. The system 10 

2 0 allows a client to define regions such as regions A and B 
indicated at 26 and 28, respectively. Region A 26 is 
shown as a region consisting of noncontiguous 
geographical areas 26a and 26b for illustrative purposes. 
Thus, a message playlist can be sent to message playback 

25 devices 24a, 24c and 24d at sites 18 and 22 if region A 26 
is specified, or to message playback devices 24a and 24b 
at sites 18 and 20 if region B 28 is specified. The 
ability to define regions is advantageous because multiple 
sites with similar programming requirements (e.g., sites 
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in the same geographical area or sites performing the same 
customer service function) can be programmed by specifying 
a single playlist at one of the computers 14. 

As shown in Fig. 2, each message playback device 24 
5 is preferably provided with a compact disc (CD) or discs 
35 on which messages have been recorded. Messages, 
however, can also be stored and distributed on other 
storage media such as an integrated circuit or a magnetic 
disk. Accordingly, the message playback devices 24 can be 

10 configured in accordance with the present invention to 
access different types of storage media and discrete, 
individual messages stored thereon. Businesses and other 
concerns employing the system 10 request certain messages 
which are recorded and then written to optical discs. The 

15 optical discs are then distributed to each remote site 
associated with these businesses and installed at each 
corresponding message playback device 24 . The frequency 
with which the discs are distributed can vary, depending 
on the needs of the businesses to update message data. 

20 The discs for a business are preferably identical at each 
message playback device 24 . 

The discs can comprise several related messages, 
which differ only by reference to a different season or 
recurring event or interest rate, for example. Users can 

25 therefore select the appropriate message (s) when necessary 
and thereby reduce the frequency of updating the discs 
with new messages and then distributing them. For 
example, a manager for a chain of five retail stores can 
program message playback devices at each of the stores to 





- 11 - 



alternately play messages CI and C2 , which correspond to 
announcements for everyday discount prices at 10% off list 
price and regular store hours and locations, respectively. 
During a sale, the manager can change the playlist to 
5 include messages CI and C3 , that is, a message announcing 
3 0% savings during the sale event. At the end of a 
calendar year, the manager can modify the playlist to 
include messages C3 and C4 corresponding to announcements 
for extended business hours and 50% savings. Messages CI, 

10 C2, C3 and C4 can all be recorded onto the CDs 35 in 
advance and programmed for play as needed. When a user 
(e.g., the manager) creates a playlist, the client 
computer 14 is programmed to prompt the user to specify an 
effective date, that is, the date after which the server 

15 12 can transmit a command to play the messages on the 
playlist to the intended remote sites. Thus, a user can 
modify a playlist (e.g., replace a message on a playlist 
with another message from a CD 35) in advance of the 
actual date after which the other message is intended to 

20 be played at a remote site (e.g., in advance of a sale 
date) . 

The computers 14 transmit the message playlists and 
other information pertaining to selected remote sites 18, 
20 or 22 to the server 12. The playlists comprise, for 
25 example, the identification codes (e.g., CI, C2 , and so 
on) of selected messages on the CDs that a business wishes 
to have played, the sequence with which the selected 
messages are to be played, and the remote sites for which 
a playlist is intended. The identification codes are 






- 12 - 



preferably alphanumeric codes. The server 12, in turn, 
generates control signals for the message playback devices 
at the selected remote sites to play the selected 
messages. In accordance with the present invention, the 
5 server 12 converts message identification codes from 
playlists received from the computers 14 into 
corresponding track numbers on the CDs which are 
incorporated into the control signals. For example, the 
server 12 determines a track number corresponding to a 

10 message on a playlist by consulting a track legend stored 
in a memory device 74 of Fig. 4 (e.g., tables 94 and 96 
described below in connection with Figs. 11 and 12) . The 
track legend stores the track numbers on the disc(s) 35 
and the unique identification codes corresponding to 

15 respective messages. The track numbers of a particular 
message can vary among the CDs at the different remote 
sites . 

The server 12 preferably transmits control signals 
comprising playlists to a subcarrier radiopaging company 

20 30 for radiopaging the remote message playback devices 24 
via a communication link 31. Other types of communication 
links 31, however, can be used such as a satellite 
communication link, a microwave link, a PSTN, an optical 
fiber network or other communications link. Further, the 

25 server 12 can communicate with the radiopaging company 30 
via the communication link 16 or another communication 
link 17. 

With reference to Fig. 2, each message playback 
device 24 preferably comprises an optical disc player 32 
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{e.g., a CDP) , and a receiver circuit 34 which is adapted 
to process control signals transmitted via the 
communication link 31 into command signals for the optical 
disc player 32 . The optical disc player preferably 
5 comprises a speaker output or other output 41 which is 
connected to at least one advertising device such as a MOH 
telephone system 44, a public address system 45, and a 
visual display device (e.g., an electronic sign) 47. The 
receiver circuit 34 can be implemented on a circuit board 

10 (not shown) mounted inside the chassis of a commercially 
available optical disc player. The optical disc player 3 2 
can be, for example, a Model CDP-297 compact disc player 
available from Sony Corporation of America,. Park Ridge, 
New Jersey. The optical disc player 32 comprises a disc 

15 carousel 36, cartridge or retractable shelf adapted to 
receive one or more optical discs 35, an optics system 3 8 
for reading data from an optical disc, an audio output 
circuit 3 9 for generating audio signals from signals 
received from the optics system 38 and providing the audio 

2 0 signals to a speaker output 41, and a controller 40 for 
controlling the CDP components 36, 38 and 39. 

As stated previously, the optical disc player 32 can 
be connected to a conventional MOH telephone system 44 
having on-hold messaging capabilities such as the Merlin 

25 System Model 1030 manufactured by AT&T, Parsippany, New 
Jersey, or the Elect ra Mark II Series telephone system 
with Model TSW-E circuit card manufactured by NEC America, 
Melville, New York. It is to be understood, however, that 
the telephone system 44 can also be a PBX or other type of 
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telephone system such as an automated telephone answering 
system. An optional audio amplifier 42 (e.g., a Model 1701 
amplifier manufactured by University Sound, Inc., Sylmar, 
California) can be connected between the optical disc 
5 player 32 and the MOH telephone system 44, if their 
respective output signal levels are different, to improve 
the volume level and clarity of the audio signals heard by 
callers accessing the MOH telephone system 44 via a 
communications network 46 and telephones 48 or other 
10 telecommunications access devices. The network 46 of Fig. 
2 and the network 16 of Fig. 1 are preferably the same 
PSTN. 

With continued reference to Fig. 2, the receiver 
circuit 34 preferably comprises a microcontroller 50 

15 programmed in accordance with the present invention, a 
receiver 52 and an antenna 54 . The receiver 52 is adapted 
to demodulate signals (e.g. radiopaging signals) received 
from the communications link between the server 12 and the 
message playback devices 24 (e.g., via the radiopaging 

20 company 30) . The demodulated signals are preferably 
stored in a non-volatile memory device 55. The 
microcontroller 50 decodes the stored signals and converts 
them into command signals for the controller 40. The 
controller 40, in turn, controls the optical disc player 

25 32 to queue up tracks corresponding to selected messages 
in the playlist for playing. In accordance with another 
embodiment of the invention, the system 10 can be 
configured with a single computer 14 and no server 12 . 
For example, the computer 14 can be located in an office 
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within a building and connected directly to one or more 
message playback devices 32 in the building such as a 
public address system 45 and a number of signs 47 via a 
wireline communications link (e.g., a local area network) 
5 and modem 53 . 

While the system 10 is described for use with a MOH 
telephone system 44 to accommodate customers awaiting 
assistance via telephones 48, the system 10 can be adapted 
to provide remote programmability for other types of audio 

10 and multimedia message delivery equipment such as a 
programmable public address system 45, an electronic sign 
47 or a videoconferencing device 49. The optical disc 
player 32 can be configured as a multimedia device having 
a video output device 49 for processing data accessed from 

15 the CD(s) 35. For example, messages can include video 
commercials for a videoconferencing device 4 9 at a remote 
site having a corresponding audio message on the speaker 
output 41, or a still picture (e.g., a picture of a 
client's business premises) that is useful with different 

2 0 audio messages. The videoconferencing device can receive 
multimedia messages directly from the multimedia optical 
disc player 32 or from the MOH telephone system 44. 

Thus, in accordance with the present invention, each 
message playback device 24 at the remote sites 18, 20 and 

25 22 can be programmed by users operating at least one of 
the computers 14a and 14b to play messages stored on 
optical disc(s) 35 on a MOH telephone system 44 or other 
advertising device having a speaker or display device. 
Further, the system 10 simplifies the process of selecting 
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message playlists and allows a system user to more 
effectively maintain a promotional program for customers 
placed on- hold, or in the broadcast area of a public 
address system, in view of a programmable display or 
5 operating a multimedia computer. 

With reference to Fig. 3, each client computer 14 
comprises a central processing unit (CPU) 56 (e.g., a 
microcontroller), a memory device 58, a display device 60 
such as a video monitor, and at least one input device 62 

10 such as a keyboard and preferably also a mouse. The 
computer 14 communicates with the server 12 in a manner 
described below via a modem 64 and a universal 
asynchronous receiver/transmitter 66 . Similarly, as shown 
in Fig. 4, the server 12 comprises a CPU 68, an input 

15 device 70, a display device 72, and a memory device 74. 

The server 12 comprises a network interface 76 to 
communicate with other devices via the network 16 . The 
server 12 is depicted in Fig. 4 as being connected via 
PSTN 16 to client computers 14a, 14b and 14c and to paging 

20 companies 30a and 30b for illustrative purposes. 

The system 10 software will now be described with 
continued reference to Fig. 4. The system 10 preferably 
employs a distributed database to manage information 
relating to the system 10 configuration, the paging 

25 companies 3 0a and 30b, capcodes for radiopaging signals, 
hardwired line connections, the histories and 
configuration of each message playback device 24, client 
accounts, among other aspects of the system 10. The 
distributed database comprises a number of local or client 
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databases 78 and a server database 80 maintained by the 
server 12. The server database 80 is synchronized with 
each of the client databases 78 in a manner described in 
further detail below. The server database 80 preferably 
5 stores records corresponding to the records maintained at 
each of the client computers 14 . Since database changes 
(e.g., deletion of a message from a previously transmitted 
playlist) are generally initiated by clients via the 
client computers 14, the client databases do not overlap. 

10 Thus, record level arbitration is minimal. 

In accordance with an embodiment of the present 
invention, the records! in the distributed database are 
organized as a number of tables. The server database 80 
preferably manages all of the tables, and each of the 

15 client databases 78 stores a subset of the tables, that 
is, those tables that are pertinent to that particular 
client. The distributed database can be created using, for 
example, the ACCESS 2.0 relational database architecture 
developed by Microsoft Corporation, Redmond, Washington. 

2 0 Each client maintains its client database 78 via its 

client computer (s) 14. In other words, a client can use 
more than one computer 14 to access the server 12 if there 
is equipment (e.g., a client server (not shown)) to 
arbitrate client database modification requests generated 

25 by different client computers. The individual client 
databases 78 maintain records of messages, regions, remote 
sites and playlists pertaining to that particular client. 
A client database 78 can also be maintained for more than 
one person and/or business entity if those persons or 
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businesses communicate with the server 12 using the same 
computer (s) 14 and client database 78. 

The server 12 is preferably implemented as a set of 
applications on the CPU 68 and operates as a dedicated 
5 computer. In addition, the server 12 preferably operates 
as a communications hub in the network 16, establishing 
connections with the computers 14 to receive database 
changes therefrom and to synchronize the server database 
80 to the client databases 78. Synchronization involves 

10 downloading database changes from each client database 78 
to the server database 80. The server 12 then organizes 
the database changes into control signals which are sent 
to the paging companies 30a and/or 3 0b for broadcast to 
the message playback devices 24 . The server 12 also 

15 performs administrative functions such as maintaining 
paging accounts and client billing. 

The system 10 is preferably implemented using a 
demand-based client-server architecture to optimize 
telephone connect time during the synchronization process. 

2 0 A user can preferably access the client application at the 
computer 14 at any time. The client application, however, 
preferably must receive a log-on request message from the 
server 12 after a connection is established to begin 
synchronization. Thus, to optimize the call connection, 

25 the client computer 14 is not connected to the server 12 
while the user is making changes to the client database. 
Once all of the database changes have been entered at the 
computer 14, the user can establish a call connection and 
synchronize with the server 12 . 
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The client computers 14 are each preferably 
programmed using an on-demand, WINDOWS™ -based client 
application on the CPU 56 which allows users to define 
remote sites, regions and message playlists. Each client 
5 database 7 8 comprises data relating to the identification 
codes corresponding to each message on the optical discs, 
the playlist currently in use at each remote site 
associated with the corresponding computer 14 , alternate 
playlists (e.g., playlists having future effective dates), 

10 and data relating to each site and region associated with 
the corresponding client (s), among other data. Each 
computer 14 is also programmed to provide a graphic user 
interface by generating screens on the display device 60 
for guiding a client when making changes to the client 

15 database 78 (e.g., defining a new site, region or playlist 
or modifying existing records) . A number of the screens 
are described below in connection with Figs. 19-28. The 
screens are created in a conventional manner using, for 
example, the relational database software such that data 

2 0 entered into the fields on the screens are processed and 
stored to tables and are otherwise used to generate 
message playlists. 



25 administrative tables that are specific to the server 12. 
For example, at least one table 82, as shown in Fig. 5, is 
stored in the server database 80 for each of the message 
playback devices 24 . The configuration tables for the 
message playback devices 24 comprise a number of fields 



Database tables will now be described with reference 



to Figs . 



5-18. 



The server database 80 comprises 
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such as customer account number, an electronic serial 
number uniquely identifying that particular message 
playback device, at least one field specifying the regions 
in which that message playback device operates, a 
5 broadcast method number (BMN) , and preferably one or two 
other fields with auxiliary BMNs, model and firmware 
identification numbers corresponding to the message 
playback device hardware and software, respectively, dates 
indicating when the message playback device configuration 

10 was last programmed and when the status of the message 
playback device was last read. In addition, the 

respective tables 82 for the message playback devices 24 
are programmed to store information regarding successful 
transmission statistics, as well as fields for indicating 

15 total number of pages received, total number of corrupted 
pages, as well as total number of pages transmitted. A 
server port table 84 is depicted in Fig. 6 for storing 
data relating to ports used by the server 12 . 



2 0 the server database 80 and each of the client databases 
78, such as a customer account table 86 (Fig. 7) , a site 
table 88 (Fig. 8) , and a region table 90 (Fig. 9) . The 
customer account table 86 comprises fields for storing 
information such as customer account number, current and 

25 previous passwords, biographic information such as 
customer name, address, telephone number, facsimile number 
and contact name. Further, the customer account table 86 
can comprise information such as name of the sales 



A number of administrative tables are shared between 
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representative serving the customer and the dates on which 
the customer account table was created and last modified. 

The site table 88 preferably comprises fields for 
storing information such as customer account number, site 
5 name and key, a synchronization code, site address, site 
manager name, an electronic serial number for the message 
playback device 24 serving that site, hours of operation, 
telephone and facsimile numbers, as well as dates on which 
a site table was created for a particular location and 

10 when the site table was last edited. 

The site table 8 0 preferably contains information 
relating to a single site. Each site preferably specifies 
the location of a single message playback device 24. 
Synchronization codes are described with reference to Fig. 

15 10 . In order to reflect the state of tables or records in 
a client database 78, and records on the server 12 during 
synchronization, shared records are provided with a S STATE 
field. The S STATE field is provided with a value, as 
shown in the table 92 in Fig. 10, by the CPUs 56 or 68, 

2 0 depending on the transaction occurring between a client 
computer 14 and the server 12 . 

A region table 90 relates a local region name to a 
broadcast method. A region table 90 preferably comprises 
fields such as customer account number, region name, key, 

25 and status, a broadcast method number, a region number, a 
description of the region, as well as dates on which the 
region table was created and last modified. 

In addition to administrative tables, the server and 
client databases 78 and 80 share message tables. Each 
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message in the system 10 is preferably defined using two 
tables, that is, a message table 94 (Fig. 11) and a track 
correction (TCOR) table 96 (Fig. 12) . The message table 
94 defines a message currently in existence for a 
5 particular customer account. The TCOR table 96 provides 
per- site track translation to allow for the use of non- 
standard compact discs used at the various sites. Unlike 
the customer account, region and site tables 86, 90 and 
88, changes to message tables 94 are created at the server 

10 12 and approved by clients. The synchronization status 
fields in these tables 94 and 96 therefore have different 
definitions, as indicated in the table 98 in Fig. 13. A 
synchronization status field in the message table can be 
provided with one of preferably five different status 

15 indicators (e.g., an integer number or other code) to 
indicate: (1) that a message has been entered into the 
server database 80 and needs to be sent to the client 
computer 14; (2) that a message has been downloaded to the 
client for approval; (3) that the message has been 

20 approved by the client; (4) that the message has been 
changed in the server database 80 and needs to be 
presented to the client; and (5) that the message has been 
approved in the client database 98 but the server needs to 
be notified. 

25 In addition to the synchronization status field, a 

message table 94 comprises fields for storing information 
such as a customer account number, a message code which 
uniquely identifies that message, a descriptive title for 
the message, an indication of whether or not the message 
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is a signature track, a library CD number and track 
number, a code for indicating whether or not the message 
was created using a mail or female voice, a field for 
storing the text of the message for generation if desired 
5 on a client computer screen 60, introduction time in 
seconds, reading time in seconds and trailer time in 
seconds, and the date on which the message was recorded. 
Entries in the message tables specify actual audio tracks 
on compact discs located at sites, as well as on the 

10 account library compact disc set. The unique message codes 
in the message tables preferably consist of a single 
letter followed by a number. The letter "S" preceding a 
message code indicates that the message is a signature 
track which is characterized by an additional signature 

15 index. The signature index allows, for example, 

intuitive representation of a single track which is used 
differently for different sites . The message code 
preferably comprises 32 bits, that is, an eight bit binary 
code for representing one of the letters A through Z, 

20 eight bits to denote the message number, and an additional 
eight bits to indicate the signature index. The remaining 
bits are preferably zeroes. When playlists are processed, 
the signature index is ignored. 

The track correction table 96 provides a correction 

25 for terminated or otherwise misplaced tracks on a per-site 
basis. If a record exists for a particular site and a 
particular message, the specified correction in the table 
96 overrides a track field in the message record; 




r 
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otherwise, a track assignment field in the message table 
94 indicates that the message is an uncorrected track. 

The system 10 preferably uses regions to describe 



5 coverage, however, are described by a paging carrier, a 
capcode, and a region selector. The translation between 
the physical coverage model and the region model is 
defined by a broadcast method table 100 (Fig. 14) and a 
carrier table 102 (Fig. 15) . The broadcast method table 

10 100 preferably comprises fields for storing broadcast 
method number, carrier key, a per-site identification 
number or PIN, a capcode, a format code, a frequency, a 
bandwidth and a coverage region. The broadcast method 
table 100 provides a relationship between a broadcast 

15 method and particular paging account for the system 10. 

The paging carrier table 102 preferably comprises fields 
for storing carrier name, carrier key, input format code, 
telephone number or computer on-line address, modem 
initialization string, ixo/TAP response and maximum packet 

20 size. 

A playlist transmitted from a client computer 14 to 
the server 12 comprises a list of messages and a list of 
destinations which are represented in three related 
tables, that is, a playlist root table 104 (Fig. 16) , a 
25 playlist message table 106 (Fig. 17) and a playlist site 
table 108 (Fig. 18) . The tables are related using a 
sequence field. The sequence field in the playlist 
message table 106 and the playlist site table 108 
comprises a command sequence identification code. The 



broadcast coverage . 



The physical aspects of broadcast 
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sequence field in the playlist root table 104 comprises a 
playlist sequence number. The other fields in the 

playlist root table are customer account, number, playlist 
name, a flag to indicate whether or not the playlist is 
5 urgent , a date on which to send the command to play the 
message playlist to the message playback devices 24 , a 
creation date, a date indicating when the playlist root 
table 104 was last modified, a scheduled transmission date 
(i.e., a date that indicates when the playlist is 

10 transmitted, as opposed to when the message playback 
device 24 provides the compact disc player with the 
command to begin use of the playlist) , and a 
synchronization status field. 

The playlist message table 106 comprises fields for 

15 storing message codes for each of the messages in the 
playlist, as well as data indicating the relative position 
of the messages in the playlist according to a position or 
POS field. Messages characterized by lower POS values are 
played before messages having higher POS values. Further, 

2 0 if the message code specifies a signature track, then a 
message from a custom table is played; otherwise, the 
message code field specifies a message in the message 
table. 

The playlist site table 108 comprises data relating 
25 to customer account, site key and site flag in addition to 
the comment command identification in the sequence field. 

The playlist site table 108 indicates progress of 
playlist transmission and stores a history of commands to 
determine which commands are sent to what sites. When a 
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playlist is created, a client specifies which sites are to 
receive it. The set of sites is converted into multiple 
entries in this table 108 which describe the actual 
transmissions that are intended to reach all sites . The 
5 entries in the playlist site table 108 are provided to the 
server 12 during the synchronization process . When the 
server 12 transmits the command (i.e., message track 
numbers and site numbers for message playback devices 24 
destined to receive the command) , the server 12 scans 

10 through all of the playlist site table entries. The 
server 12 proceeds to prepare signals for transmission to 
each of the sites listed in the playlist site table. 
Following transmission, the server 12 changes the SENT 
field in the playlist site table 108 to a value 

15 corresponding to the condition "true" . Further, the 
server 12 changes the SENT field in all other records 
related to the transmission to a value corresponding to 
"true", as well. 



2 0 programmed to generate a number of screens to guide a 
client through the process of generating message 
playlists, as well as modifying existing playlists for 
transmission to sites and regions. The client application 
allows a client to describe relationships between sites, 

25 regions, messages and playlists in graphical terms which 
are then recorded in the client database 78. A number of 
the screens are depicted in Figs. 19-28. As shown in Fig. 
19, a client computer is programmed to generate a log-on 
screen 110 which prompts the client to enter an account 



The client application on each of the computers 14 is 
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number and a password. Once a valid password is entered, 
the computer 14 is programmed to generate a main window 
screen 112, as shown in Fig. 20. 

The main window screen 112 is divided into three 
5 areas 114, 116 and 118, entitled Sites and Regions, 
Message Library and Playlist Register, respectively. The 
Sites and Regions area 114 shows a tree list representing 
regions as folders. Sites are represented as small 
buildings, as described below in connection with Fig. 24. 

10 Sites are displayed when their corresponding region is 
double -clicked open using a mouse, for example. Four 
buttons 120, 122, 124 and 126 in this area 114 allow the 
client to add, delete and edit regions (e.g., regions 26 
and 28) and sites (e.g., 18, 20 and 22). The Message 

15 Library area 116 shows a list of all of the messages 
available to the client, along with message titles and 
message codes. Double -clicking on any message in the list 
or clicking on the viewer button 132 opens a corresponding 
message viewer screen (e.g., screen 128 or 130 which are 

20 shown in Figs. 21 and 22) . A message viewer screen allows 
the client to view message parameters, to play a message 
on a CD-ROM at the computer 14 if the computer 14 is 
provided with an optional CD drive 131 (Fig. 3) and sound 
card (not shown) , and to accept the message for playback 

25 from CDs located at selected remote sites. Finally, the 
Playlist Register area 118 indicates all pending 
playlists, as well as a history of playlists transmitted 
to the remote sites. Double-clicking on a pending playlist 
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converts this area 118 into a Playlist Editor area 134, as 
shown in screen 133 of Fig 23 . 

With continued reference to Fig. 20, if one of the 
region names (e.g., Cincinnati) in the area 114 is 
5 highlighted, the computer generates a screen 136, as shown 
in Fig. 24, which lists all of the sites associated with 
that region (e.g., Forest Park, Goshen and so on) . With 
reference to Fig. 25, the client can specify certain 
parameters relating to a region by depressing the button 

10 122 on screen 136 to obtain the screen 138. Because a 
region is preferably an abstract entity with most of its 
details managed by the server 12, in accordance with an 
embodiment of the present invention, the client is 
preferably limited to changing region name and description 

15 in fields 140 and 142, respectively. On the other hand, a 
client preferably has more latitude to edit data relating 
to a site, as indicated in Figs. 26, 27 and 28. The 
screens 144, 146 and 148 depicted in these Figures 
illustrate how a client can enter biographical data 

2 0 regarding a site, the sequence of messages in a current 
playlist at a particular site, and a list of pending 
playlists and their effective dates (e.g., send dates) . 

With reference to Fig. 21, the message viewer screen 
12 8 or 13 0 allows a client to preview the text or message 

25 copy, introduction, read and trail times of the message, 
whether or not the message was generated using a male or 
female voice, as well as the title and message code 
corresponding to that message. As stated previously, the 
message viewer screen 128 or 13 0 can be used to review 
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messages currently available on CDs distributed to remote 
sites, and new messages received from the server 12 for 
release approval . 

With reference to Fig. 20, by clicking the "add" or 
5 "delete" buttons 150 and 152, the client can add or remove 
a playlist from the Playlist Register area 118. By 
clicking the "edit" button 154, or double -clicking the 
playlist name in the area 118, the client can obtain the 
screen 133 in Fig. 23. The Playlist Editor area 134 

10 indicates whether or not a playlist has an effective 
transmission date, the sites at which the playlist is to 
be played, as well as the messages in the playlist. Sites 
can be specified by dragging them on the display 60 via a 
mouse or other input device 62 from the Sites and Regions 

15 area 114 to the site editor area 135. Alternatively, the 
"All" button 156 can be clicked to automatically list all 
sites in the region highlighted in the area 114 . Messages 
can be selected by clicking them in the Message Library 
area 116 or on the message viewer screen (e.g., screen 128 

20 or 130). "Remove" and "Clear" buttons 158, 160, 162 and 
164 are provided to remove selected ones or all of the 
sites and messages in the Playlist Editor area 134 . The 
entries in the Playlist Editor area 134 can then be saved 
or canceled by clicking the "Save" button 166 or the 

25 "Cancel" button 168, respectively. The computer 14 is 
programmed via the client application to initiate a 
telephone call via its modem to the server 12 to relay the 
sites and regions configuration or playlist register data 
thereto. The telephone call is preferably initiated at 
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midnight on the day that the "Save" button was depressed. 

If the "Urgent" button is clicked, the telephone call is 
initiated immediately after the "Save" button is clicked. 

The operation of the server 12 will now be described 
5 with reference to Fig. 29. The server 12 is the data 
interchange point of the system 10 . The server 12 accepts 
calls from client applications at corresponding computers 
14 and generates control signals for the radiopaging 
company 30 or other communication link. The server 12 

10 transmits the control signals to remotely located message 
playback devices 24 having optical disc players 32 and one 
or more compact discs containing messages to control which 
of the messages are played and when they are played. The 
server 12 also collects billing information and maintains 

15 customer accounts with each client . The server 12 is 
programmed to perform client input tasks 170a, 170b, 170c 
and 170d which are preferably perpetual tasks that monitor 
a particular port on the server 12 for incoming calls from 
client computers 14. Four client input tasks are shown 

20 for illustrative purposes and shall be collectively 
referred to using reference numeral 170 . The server 12 
performs paging output tasks 172a, 172b, 172c and 172d 
which run on-demand, passing data packets to a paging 
company 30 for broadcast as radiopaging signals in such 

25 protocols as TNPP, TAP/ixo and SNPP. Similarly, four 
exemplary tasks are shown and shall hereinafter be 
collectively referred to as tasks 172 . The server 12 is 
programmed with a daemon 174 which analyzes changes made 
to the database 80 by client input tasks 170, and sends 
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packets to paging output tasks 172 to relay programming 
information to the remote message playback devices 24 . 

The client input tasks 170 can control a serial I/O 
port, a TCP/IP port or other communications interface, and 
5 are operable to accept calls from client applications on 
computer 14. The dialog between client input tasks 170 and 
client applications is preferably performed using a custom 
data transaction protocol (DTP) , which is described below. 
When communicating with a client computer 14 , each of the 

10 client input tasks 170 at the server 12 operates as a 
server, and the client application for that computer 14 
operates as a slave . Communication is based on 
transactions which are initiated by one of the client 
input tasks (e.g., task 170a) and responded to by, for 

15 example, the client computer 14a. When a call is 
detected, the client input task 170a controls the computer 
14a to prompt the client to enter a password and an 
account number. During synchronization, the client input 
task 170a also requests a list of all of the sites stored 

20 in that client database 78, all of the regions stored in 
that client database, as well as all of the playlists 
created at that computer 14a. This represents a method of 
passing forward notification of deleted sites, regions or 
playlists. The client input task 170a subsequently 

25 requests modified site records from the client computer, 
and continues to do so until the client computer responds 
with a null record to indicate that no more modified 
records exist. Similarly, the client input task 170a 
requests modified region records and modified playlist 
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records from the client computer 14a, and does so until 
null records are received. The client input task 170a 
subsequently reports modified site records, modified 
region records and modified playlist records to the client 
5 application at the computer 14a. The client is therefore 
informed of the site records and region records that have 
been administratively activated or changed. The reporting 
transactions continue as long as the modified region and 
site records remain in the server database 80. The client 

10 is also informed of playlist records that have been 
transmitted. These reporting transactions continue as 
long as the modified playlist records remain in the server 
database 80. The client input task 170a is programmed to 
then conclude the session with the client computer 14a and 

15 terminate the connection on the network 16. 

Paging output tasks 172 are protocol processing 
modules, which accept command packets generated by the 
server daemon 174 and deliver them to a paging company 3 0 
via a communication link 16 or 17 . The server daemon 174 

2 0 is preferably a perpetual software processing module which 
monitors changes made to the server database 8 0 via client 
input tasks 170, determines when and how to update the 
message playback devices 24 and generates command packets 
accordingly. For example, when a client creates a new 

25 site or region, or makes a change to an existing site or 
region, one of the client input tasks (e.g., task 170c) at 
the server 12 communicates with the computer 14 (e.g., 
computer 14b) to receive data from that client 
application. The data is entered, for example, using the 
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screens depicted in Figs. 20 and 23. The client input task 
170c subsequently records these modifications in the 
server database 8 0 during the next synchronization 
process . Depending on the nature of the change requested 
5 by the client, the server daemon 174 preferably operates 
in one of two ways. Since human interaction is preferably 
required to create new sites and regions in a client 
database, the tables for the new sites and regions contain 
an S STATE field which is set to the parameter 

10 corresponding to the "New" state. The client computer 
(e.g., computer 14b) is programmed to retrieve data 
entered in the fields on the screens (e.g., screen 123) 
and to automatically provide it to account, site or region 
tables as necessary. The client computer 14b is also 

15 programmed to provide the modified tables to the server 
12, along with playlist root tables 104, playlist message 
tables 106 and playlist site tables 108, during 
synchronization . 



20 S STATE field set to the variable "New" , the daemon 174 
takes no further action since an administrator at the 
server 12 processes the data received from the client 
computers 14 at a later time to set up the necessary 
server database records . When administrative changes are 

25 made by a client to an existing record or table, such as 
changing telephone numbers or points of contact, the 
server daemon 174 also takes no further action since such 
changes have no impact on the communication path to the 
message playback devices 24 . When the region assignment of 



When the server daemon 174 encounters tables with the 
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a particular site is changed, the server daemon 174 
generates and sends a command packet to the message 
playback device 24 at that site to change the region 
assignment at that computer. 



send playlists to remote message playback devices 24 to 
control the sequence of messages played by, for example, 
CD players at the various sites 18, 20 and 22. Since the 
transmission method is preferably a one-way data 

10 broadcast, the server is programmed to conserve air time. 
Playlists are most efficiently sent to sites within 
particular regions . Each packet generated by the paging 
output tasks 172 comprises a header having bit flags . The 
bit flags are set to indicate which region numbers have 

15 been selected. All of the sites in a region are 
preferably provided with the same capcode . The flags, 
therefore, are used as a second level of discrimination. 
Use of regions assigned with unique identification codes 
allows a single playlist to be received by every message 

2 0 playback device 24 in a single region, or in a cross- 
section thereof, or in as many as 16 regions, for example. 

As stated previously, the system 10 is configured to 
allow programming of individual sites and offers 
2 5 advantages such as the ability to play signature tracks at 
certain sites or regions . The more differences that exist 
between receiving sites; however, the more air time that 
is required by the system 10 . The system 10 is therefore 
configured to optimize air time to manage various 



5 



The primary task of the daemon 174 is preferably to 
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situations . 



For example 



several playlists can be 



scheduled for the same transmission date with some of the 
playlists specifying sites in the same region. In some 
instances, playlists can specify only some of the sites in 
5 a region and leave other sites unchanged. Finally, track 
corrections can exist in one or two sites within a region 
and thereby complicate a regional playlist . These three 
types of situations can also be combined to determine the 
optimal strategy for transmitting a set of playlists . The 

10 server 12 is programmed to set up two models. First, the 
server 12 attempts to create one playlist that covers the 
largest number of sites . The server 12 calculates the 
total number of data required to transmit the playlist to 
all the sites in the affected regions and the individually 

15 addressed playlists being sent to sites not intended to 
play the first playlist. Second, the server 12 calculates 
the total amount of data required to individually address 
each site affected by the playlists . The server 12 
generates command packets in accordance with the method 

20 requiring the least amount of data and forwards the 
command packets. to one of the paging output tasks 172. 

As stated previously, the client application at each 
computer 14 is programmed to generate screens to guide the 
user in describing relationships between sites, regions, 

25 messages and playlists. Activities are subsequently 

recorded by the client computer 14 in the client database 
78 maintained at that computer. The database 78 is 
subsequently synchronized with the server database 80 at, 
for example, regular intervals to record changes made by 
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clients at the server database 80. As stated previously, 
the protocol used for communication between client 
computers 14 and the server is preferably a customized 
Data Transaction Protocol (DTP) . The DTP is a session- 
5 based, end-to-end protocol, which is designed to provide 
positive acknowledgment upon completion of each 
transaction. Transactions are preferably initiated by the 
server 12 regardless of whether they require changes to 
the server database 80 or to a client database 78 . The 

10 DTP comprises two layers, that is, an upper layer and a 
lower layer. The lower layer corresponds approximately to 
the Data, Link, Network, Transport, Session and 
Presentation layers specified in the Open System 
Interconnection (OSI) reference model. The upper layer 

15 corresponds approximately to the Application layer of the 
OSI reference model . The lower level shall be described 
herein as a custom protocol; however, it can also be 
implemented as a wrapper for an industry standard protocol 
such as TCP/IP or IPX/SPX. Client applications and server 

2 0 software modules preferably run in a 32 -bit WINDOWS™ 
environment . 

Transaction in DTP between client computers 14 and 
the server 12 preferably comprise request messages and 
response messages. The server 12 preferably initiates a 
25 transaction with a request message, and the client 
computer preferably concludes the transaction with a 
corresponding response message. A request message can, 
for example, request a client computer 14 to change its 
database 78 or pass information required for the server 12 
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to change the server database 80. A response message, for 
example, reports that a change is complete or returns 
information from the client database 78 to the server 12 . 
These transactions will be described in further detail 
5 below. 

As stated previously, the lower layer provides the 
functionality corresponding to OSI reference model layers 
2-6. It is therefore useful for operating with a physical 
layer comprising a UART 66, a modem 64 and a telephone 

10 line provided in each of the client computers 14 since it 
is a connection-oriented protocol. The lower layer 

converts request messages or response messages into 
preferably a single packet. The lower layer, therefore, 
relies on the upper layer for packet acknowledgment and 

15 packetizing. The lower layer notifies the upper layer 
when it is ready to receive a new message, and 
subsequently converts new messages into packets by 
prepending Start Flag, Length and Sequence bits and by 
calculating and appending a CRC-16 value, as shown in Fig. 

20 30. When the lower layer receives packets, it validates 
the CRC-16 and checksum values. Packets having an 
incorrect checksum are ignored, as are packets that have 
already been processed. Valid packets are passed to the 
upper layer. 

25 The lower layer operates in one of two modes, 

depending on whether it is servicing a client computer 14 
or the server 12. In the client computer 14, the lower 
layer initiates a modem 64 call and notifies the upper 
layer when the first message is received from the server 
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12. In the server 12, the lower layer places the modem 76 
therein in an auto- answer mode and requests the first 
message from the upper layer when a call from a client 
computer 14 is detected and a connection with the server 
5 12 is established. 

The upper layer operates as part of the client 
application or the server software (i.e., client input 
task 170) . The upper layer manages communication on a 
transaction level, generating request messages and 

10 response messages as necessary. 

A transaction is preferably encoded as an eight -bit 
function code value, followed by an arbitrary number of 
encoded, typed fields, as indicated in Figs. 31-40. As 
stated previously, a transaction comprises a request 

15 message from the server 12 and a response message from a 
client computer. A number of transaction types can be 
created for use in the system 10 . Exemplary transactions 
will now be described in connection with Figs. 31-40. 



20 intended to be the first transaction after connection 
between a client computer 14 and the server 12 is 



message . The client computer 14 subsequently responds 
with a log-on response message, as indicated in Fig. 31. 
25 If the response message contains a valid account number 
and password, the server 12 continues to issue request 
messages until the session is complete, that is, after 
site, region and playlist rosters are sent, and site, 
region and playlist modification requests are sent, as 



The log-on transaction validates a session and is 



established. 



The server 12 issues a log-on request 
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described above. If the response message from the client 
computer 14 is incorrect, the server 12 preferably 
terminates the connection. As shown in Fig. 31, one of 
the fields corresponds to a new password field. If the 
5 new password field is not null, then the server 12 accepts 
the contents as the new password to be used for subsequent 
sessions on that particular account . 

The response portion of a site roster transaction is 
depicted in Fig. 32. A request message for a list of 

10 sites from the server 12 preferably comprises no fields. 
The client computer 14 sends a complete list of sites in 
its client database 78 to the server 12 . Sites in the 
server database 80 that are not found in this list are 
determined to have been removed by the client. Records 

15 (e.g., site tables 88) deleted in this manner are provided 
with flags for administrative attention by changing the 
S STATE field to SSDEL which corresponds to a code 
indicating that a record has been deleted by the client 
and requires administrative attention. Sites in the 

2 0 client list that are not found in the server database 8 0 
are determined to have been created by the user. The 
server 12 automatically adds these sites to the server 
database 80. The response segment of a region roster 
transaction is depicted in Fig. 33 and involves adding and 

25 deleting regions to and from, respectively, the server 
database 80 in a manner similar to the site roster 
transaction. A playlist roster transaction is depicted in 
Fig. 34. This transaction is similar to the playlist and 
region roster transactions, except that records are 
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deleted from the server database 80, as opposed to being 
flagged for administrative attention. 

With regard to the site modification transaction, the 
server 12 generates a request message to solicit the next 
5 site record in which changes have been made at the client 
computer 14 to which the server 12 is connected. The 
client computer 14 in return generates a response message 
having fields as indicated in Fig. 35. The fields in the 
corresponding server database record are then updated in 

10 accordance with the fields in the site modification 
response message generated by the client computer. If the 
NREGKEY field indicates that a region assignment change is 
requested, the SSTATE field in the corresponding server 
database table 88 is changed to SSPEND. If the record is 

15 new, the SSTATE field in the corresponding database table 
88 is changed to SSNEW; otherwise, the SSTATE field is 
changed to SSREADY. Similarly, in a region modification 
transaction, the server 12 generates a request message to 
solicit the next region record or table at the client 

20 computer 14 in which changes have been made. The fields 
in the corresponding server database table 90 are then 
updated in accordance with the response message shown in 
Fig. 36. If the record is a new one, the SSTATE field in 
the table 90 is changed to SSNEW; otherwise, the SSTATE 

2 5 field in the table 90 is changed to SSREADY. 

In a playlist modification transaction, the server 12 
generates a request message to solicit the next playlist 
record in which changes have been made from the client 
computer 14 to which it is connected. The fields in the 
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corresponding server database tables 104, 106 and 108 are 
updated in accordance with the response message depicted 
in Fig. 37. As with the region modification request, a 
new record is acknowledged by changing the S STATE field to 
5 SSNEW; otherwise, the S STATE field is changed to SSREADY. 
Since a playlist is represented by three tables, as 
described previously, the playlist modification 
transaction is more complex than the site or region 
modification transactions. The list of site keys in the 

10 response message corresponds to records in the playlist 
site table 108. The list of message codes corresponds to 
the fields in the playlist message tables 106, with the 
POS field being derived from the position of each message 
code in the transaction. Once a playlist has been 

15 transmitted to a message playback device (i.e., the SENT 
field Boolean value corresponding to the state "true"), 
the record at the message playback device becomes a read- 
only record that cannot be modified, but rather only 
replaced. 

20 A site modification transaction involves the server 

generating a request message as shown in Fig. 3 8 to notify 
the client computer 14 of changes made to the site table 
88. The only field effected by this transaction is 
preferably the S STATE field since this transaction type is 

25 intended to facilitate notifying the client when 
administrative changes to a site record are complete. 
Similarly, the server generates a request in the region 
modification transaction shown in Fig. 39 to notify a 




client when administrative changes to a region record are 
complete . 

During a playlist modification transaction, the 
server 12 generates a request message to notify a client 
of changes made to a playlist in the server database 80. 
Client tables are updated by the client computer 14 
according to the fields in the request message as shown in 
Fig. 40. The SSTATE field in the client table is taken 
from the SSTATE field in the request message. The 
transaction informs the client that a playlist has been 
transmitted. As with the playlist modification request 
transaction, the site keys correspond to records in the 
playlist site table 108. The message codes correspond to 
records in the playlist message tables 106, with the POS 
field being derived from the position of each code in the 
transaction. In the case where a client attempts to 
change a playlist after it has been sent to the client 
computer 14 , but before the client computer 14 has been 
notified, the server 12 ignores the modification requests 
and then notifies the client computer 14 of the change . 

The protocol for communication between the server 12 
and the message playback devices 24 will now be described 
in connection with Figs. 41-52. The message playback 
generating devices 24 are the end points of the system 10. 

As stated previously, each message playback device 24 is 
a microcomputer-based device designed for installation 
into the chassis of a compact disc player 32 (CDP) , for 
example. The message playback device is programmable to 
turn the CDP 32 on and off and to select tracks for 
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repetitive play. The message playback device is 

preferably operational in a receive-only manner and is 
programmed to select command packets from the server 12 
according to a number of parameters . Each message 
5 playback device has a unique identification code, a paging 
capcode and a region number. The region number can range, 
for example, from an integer from 0 to 15 in order to 
identify the region membership of that particular message 
playback device 24 . The message playback device can 

10 receive commands encoded into alphanumeric radiopaging or 
other non-wireline communication signals; however, the 
same command structure can be used in wireline 
communication. The encoding, however, is different for 
radiopaging to account for a limited character set and the 

15 one-way nature of radiopaging. Each radiopaging signal, 
which is sent from the server 12 through the radiopaging 
company 30 to the message playback devices 24, preferably 
comprises a sequence number, a packet length, an encoded 
command and a single bit checksum. In addition, each 

2 0 radiopaging signal preferably corresponds to a single 
packet . 

Command blocks are preferably limited such that one 
command block fits into one packet . The packets 

preferably use a limited, seven-bit character set for 
25 compatibility between several different paging systems. 
The transmission process is preferably unidirectional with 
no acknowledgment or other feedback mechanism. The 
receiver at each message playback device 24 can receive 
multiple transmissions of the same packet and replace 
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damaged characters in an original packet with characters 
in subsequent packets having superior quality. 

The command block comprises a binary data block of 
arbitrary length. A six-bit encoding process converts the 
5 eight -bit binary data into six-bit words, as shown in Fig. 
42. For compatibility with most processors, the resulting 
six-bit values are stored as eight -bit values with the 
zeros inserted into the two most significant bits . The 
packetizing process then adds a six-bit sequence number, a 

10 six-bit length code and a six-bit checksum to the binary 
data block to create a complete packet containing six-bit 
words . A character mapping process is then employed which 
uses a one-to-one map for converting six-bit words into 
seven-bit characters compatible with a paging network 30. 

15 The complete packet is then passed along with a PIN to a 
paging output task 172 at the server 12 to send the packet 
into a paging system 3 0 as an alphanumeric radiopaging 
signal . The paging output task 172 preferably uses an 
industry standard transport protocol such as ixo/TAP, TNPP 

2 0 or SNPP. 

The paging company 30 subsequently receives the 
alphanumeric radiopaging signal, processes it and 
transmits it, accordingly. Using an industry standard 
paging format such as POCSAG, FLEX or ERMES, the message 
25 playback devices 24 each receive the page and decode the 
radiopaging signals into the original seven-bit packet, 
and error condition codes of each character. The seven- 
bit packet is then unmapped into a six-bit packet. If the 
six-bit packet contains bit errors which cannot be 
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corrected using the paging format, the microcontroller 50 
retains the six-bit packet in a voting buffer (not shown) . 
Subsequent packets received with the same sequence number 
from the paging company 3 0 are provided to the voting 
5 buffer to replace damaged characters with superior quality 
characters . Once the buffer contains only undamaged 
characters, the command block is converted from six-bit 
words to the original eight-bit data block. The original 
command block is subsequently processed by the 
10 microcontroller 50 to obtain the command from the server 
12 . 

If wireline communication is employed, the server 12 
and the message playback devices 24 are preferably 
connected using RS-232 lines and operate in an 

15 asynchronous mode at 9600 baud or higher with no parity 
bits and one stop bit . The packets are preferably 
preceded by a start flag and suffixed by an eight -bit 
checksum, as shown in Fig. 43. When a message playback 
device 24 receives a packet, the packet is checked for 

2 0 errors. If the packet contains errors or is not 

completely received, the message playback device ignores 
it; otherwise, the message playback devices act on the 
command contained therein and issues a response to the 
server 12 . 

25 Wireline communication is preferably divided into an 

upper layer corresponding to an OSI Applications layer, 
and a lower layer corresponding to OSI reference model 
layers 2 through 6 . At the server 12 , the upper layer is 
preferably divided into an in-process OLE server and a 
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utility application. At the message playback device, both 
layers are preferably integrated directly into the 
microcontroller firmware. The physical layer is 

preferably RS-232C-based asynchronous communications 
5 hardware running at 960 0 bites per second. 

The command blocks for the message playback devices 
24 are depicted in Figs. 44-52. In Fig. 44, a command for 
program track list by region is depicted. The region mask 
field in the command is compared with the region 

10 programmed into the receiver 52 of the message playback 
device 24. If a 0 is found in this field, the command is 
ignored. If the command packet is accepted, the track 
numbers are stored in the non-volatile memory 55 of the 
message playback device and programmed into the controller 

15 40 and compact disc player 32. 

A command for message playlist by electronic serial 
number (ESN) is depicted in Fig. 45. The ESN field is 
compared with the electronic serial number programmed into 
the receiver 52 of the message playback device 24 

20 receiving the command packet. If a match is found, track 
numbers are stored and programmed into the compact disc 
player; otherwise, the command is ignored. The commands 
for setting the ESN, capcodes and the region number are 
depicted in Figs. 46-48. These numbers are stored into the 

25 non-volatile memory 55 of the message playback device 24. 

The format of responses generated by the message 
playback devices following receipt of command packets are 
depicted in Figs. 49-52. The message playback devices 24 
are programmed to send a command complete response to the 
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server 12 to indicate when the last received command was 
successfully completed, a command ignored response to 
indicate that the last command was ignored (i.e., because 
either the ESN or region fields did not match those 
5 programmed into the message playback device) , an EE PROM 
write failure response to indicate that the last command 
could not be completed due to failure to write to the 
memory 55 and a status report . 

The system 10 realizes a number of advantages over 

10 existing message delivery systems. The use of CD-ROM 
technology overcomes the aforementioned problems with 
endless loop cassette tapes and provides superior sound 
quality. The screens generated by the client computers 14 
allow users to graphically select locations of message 

15 playback devices 24 at which selected messages are to be 
played via a MOH telephone system or other advertising 
device, as well as subsets or regions containing several 
message playback devices 24 . The screens also permit 
users to create playlists by graphically selecting 

20 messages from a library of messages available at the 
message playback devices 24 and the order in which the 
messages are to be played. The playlists are transmitted 
to each of the message playback devices preferably via 
radiopaging or sent via a wireline communication link. 

25 Radiopaging is relatively inexpensive and minimizes 
installation costs (i.e., the message playback devices 24 
are merely plugged into an existing power outlet and no 
further wiring is required) . Thus, managers of private and 
public organizations can use the system 10 to program the 




information they wish to provide their customers via a MOH 
telephone system or other audio and/or visual advertising 
device from a remote location at any time during the day 
efficiently and cost-effectively. 

While certain advantageous embodiments have been 
chosen to illustrate the invention, it will be understood 
by those skilled in the art that various changes and 
modifications can be made herein without departing from 
the scope of the invention as defined in the appended 
claims . 




